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ABSTRACT 


This  paper  describes  CAMA  (Computer-Aided  Mathe¬ 
matical  Analysis) ,  which  is  a  system  that  attempts  to 
handle  all  conceivable  mathematical  operations,  from 
simple  numeric  procedures  to  complex  algebraic  or  set- 
theoretic  manipulations.  CAMA  operates  in  a  timesharing 
environment  with  a  large  central  computer  and  a  remote 
terminal  computer  with  graphical  devices. 

Some  of  the  features  of  CAMA  are:  the  input  and 
output  of  mathematical  symbols  in  their  usual  mathemati¬ 
cal  representation;  the  ability  to  manipulate  these  sym¬ 
bols  according  to  predefined  algebraic  laws;  the  defini¬ 
tion  by  the  user  of  other  algebraic  laws;  the  definition 
of  symbols  with  user-prescribed  meanings;  the  automatic 
translation  of  expressions  or  equations  into  any  of 
several  languages;  and  numerical  calculations.  The  user 
can  invoke  any  of  these  tasks  through  the  graphical  ter¬ 
minal  . 
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PREFACE 


The  present  (September  1970)  state  of  the  CAMA  sys¬ 
tem  is  not  exactly  as  reported  herein.  At  the  end  of 
the  CONCOMP  Project  (August  1970) ,  a  number  of  parts  of 
the  system  were  unfinished  or  in  a  non-working  condition. 
The  interpreter  and  the  macro  processor  are  in  a  good 
working  state,  although  they  still  have  a  number  of  elusive 
bugs.  The  nature  of  the  CAMA  system  requires  that  various 
parts  of  the  program  get  and  release  space  as  a  matter  of 
course.  This  practice  causes  the  internal  evidence  of 
some  of  the  bugs  to  disappear  before  we  are  able  to  look 
for  them.  However,  this  difficulty  does  not  prevent  the 
effective  use  of  the  system;  it  makes  it  only  slightly 
annoying  to  work  with. 

The  editor  is  in  and  working  well,  along  with  a  full 
range  of  other  operations  which  aid  the  user  in  construc¬ 
ting  and  debugging  programs.  All  of  the  data  structure 
functions  are  in  good  condition,  as  is  the  tasking  opera¬ 
tion  in  the  central  computer. 

During  the  evolution  of  CAMA,  all  of  the  programs  in 
the  terminal  computer,  including  such  basic  ones  as  the 
data  structure,  DF  routines,  and  RAMP,  have  undergone 
various  changes  in  structure  and  function,  and  in  their 
calling  sequences  and  return  codes.  Consequently,  a 
number  of  system  components  that  were  functioning 


IX 


previously  are  now  in  a  non- functioning  condition.  These 
include  the  symbol-defining  capability,  plotting  routines, 
the  drawing  capability,  and  several  other  minor  components. 

Several  parts  of  the  system  are  not  finished  or  are 
in  only  a  partially  working  condition.  These  include  the 
symbol  manipulating  capability  and  the  parsing  feature. 
These  features  can  be  used  by  their  coders  but  not  by  the 
general  user  at  this  time.  The  application  of  the  symbol 
manipulation  capability  to  various  problems  awaits  a  more 
usable  functioning  of  the  system  as  a  whole. 

Some  parts  of  the  system  function  more  slowly  than 
is  desirable  for  general  use.  This  slow  action  is  largely 
due  to  two  factors.  A  large  number  of  checking  procedures 
are  now  included  in  the  programs  to  help  detect  errors  and 
to  aid  in  debugging.  These  will  be  removed  as  the  use 
proves  out  various  parts  of  the  system.  The  second  most 
important  factor  is  that  many  operations  that  could  be  del¬ 
egated  to  dwell-time  tasks  are  at  this  time  done  in  se¬ 
quence  with  other  tasks.  As  the  use  of  the  system  picks 
up  these  task  will  be  reassigned. 

Even  though  the  CAMA  system  as  a  whole  is  not  quite 
complete,  in  its  present  state  it  can  be  used  to  great 
advantage  by  the  average  user.  Those  of  us  who  designed 
and  built  CAMA  have  used  it  to  build  new  sections  of  the 
system  and  to  extend  its  features,  and  in  so  doing  have 
found  that  the  general  concept  and  viability  of  the  system 
were  clearly  demonstrated. 
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1 .  SUMMARY 


This  paper  describes  CAMA  (Computer-Aided  Mathe¬ 
matical  Analysis) ,  a  system  that  attempts  to  handle  all 
conceivable  mathematical  operations,  from  simple  numeric 
procedures  to  complex  algebraic  or  set-theoretic  manipu¬ 
lations.  CAMA  is  not  a  language,  although  languages  are 
certainly  involved  in  it.  Rather,  CAMA  provides  the  user — 
mathematician,  engineer,  or  scientist — having  mathematical 
manipulations  to  perform  with  a  more  congenial  computing 
environment.  CAMA  functions  in  a  timesharing  system,  with 
a  large  central  computer  and  a  remote  terminal  computer 
with  graphical  devices.  This  paper  describes  the  overall 
objectives  and  modes  of  operation  of  the  CAMA  system;  the 

technical  details  appear  in  other  papers  and  reports. 
12-14,22) 

Some  of  the  features  of  CAMA  are:  the  input  and  out¬ 
put  of  mathematical  symbols  in  their  usual  mathematical 
representation;  the  ability  to  manipulate  these  symbols 
according  to  predefined  algebraic  laws;  the  definition  by 
the  user  of  other  algebraic  laws;  the  definition  of  sym¬ 
bols  with  user-prescribed  meaning;  the  automatic  transla¬ 
tion  of  expressions  or  equations  into  any  of  these  tasks 
through  the  graphical  terminal. 

CAMA  is  efficient  in  that  only  those  parts  which 
are  in  immediate  use  need  be  kept  in  virtual  memory  of 
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the  centra L  computer,  while  a  large  file  of  other  parts 
are  available  on  readily  accessible  and  less  expensive 
disk  files.  Numerical  output  can  be  in  the  form  of  dis¬ 
played  graphs,  or  in  more  usual  tabular  form.  Hard  copy 
of  any  graph,  equation,  or  symbolic  pattern  can  be  ob¬ 
tained  immediately,  or  at  some  later  time  at  lower  cost. 


3 


2.  INTRODUCTION 

The  introduction  of  large  timesharing  computers,  as 

well  as  small,  fast,  inexpensive  computers,  and  graphical 

devices  to  support  them,  has  made  possible  many  applications 

(1  2) 

of  the  computer  which  were  at  best  difficult  in  the  past.  ' 
Any  mathematician,  engineer,  or  scientist  who  has  had  to 
handle  mathematical  manipulations,  turn  these  into  code, 
debug  that  code,  and  plot  numerical  results,  knows  what 
tedious  chores  these  are.  With  new  hardware,  however, 
the  mathematician  or  engineer  can  now  communicate  with 
the  computer  in  more  familiar  terms,  that  is,  with  the 
same  mathematical  symbols  that  he  uses  normally  on  a 
sheet  of  paper.  The  user  can  draw  symbols,  which  in 
turn  communicate  information  to  the  digital  computer. 
Procedures  for  mathematical  manipulation  of  these  symbols 
can  be  invoked  and  the  results  transmitted  back  to  the 
user  in  the  form  of  the  symbols  he  has  defined,  and  not  in 
the  form  of  obscure  mnemonics.  CAMA  was  conceived  not  as 
a  language  for  performing  these  operations,  but  as  a  group 
of  aids  to  assist  the  mathematician  in  whatever  operations 
he  wishes  to  perform.  These  aids  include  such  things  as 
graphical  input  of  symbols  and  expressions,  symbol  manipu¬ 
lation,  translation  of  these  symbols  into  numerical  pro¬ 
cesses,  and  automatic  display  of  the  results. 
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The  designers  could  not,  of  course,  anticipate  all 
the  possible  uses  of  CAMA,  so  many  features  were  pur¬ 
posely  left  open  to  enable  users  to  define  their  own 
operations.  There  are  many  predefined  operations;  how¬ 
ever  the  knowledgeable  user  will  be  able  to  augment  the 
standard  operatic  ns  in  as  much  as  CAMA  is  flexible  and 
adaptable.  He  may  modify  the  commands,  modify  the  data 
storage,  modify  the  syntax  of  the  languages,  modify  the 
meaning  of  words,  modify  the  meanings  of  operators.  He 
may  also  define  new  symbols  and  attach  new  meanings  to 
old  symbols. 

A  CAMA  design  objective  is  ease  of  use.  A  novice, 
without  any  experience  in  programming,  should  be  able  to 
use  many  of  the  operations  without  difficulty.  For  ex¬ 
ample,  a  novice  can  sit  down  at  the  console  and  do  the 
following  operations:  select  a  group  of  symbols  to  use 
in  his  equations,  say  an  ordinary  differential  equation; 
construct  a  differential  equation  on  the  display  screen, 
def'ne  the  boundary  conditions,  and  select  a  method  of 
solution,  for  example,  Runge-Kutta.  ile  may  then  select 
the  mode  of  the  output:  a  tabulation  of  the  results  of 
the  solution  and  its  derivatives,  and/or  a  graphical  dis¬ 
play  of  the  solution.  He  may  then  cause  the  differential 
equation  to  be  solved  and  receive  the  results.  If  he  then 
wishes  to  solve  tne  differential  equation  by  a  different 
method,  he  selects  that  method  and  proceeds  as  before. 
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Provided  the  user  was  acquainted  with  differential  equa¬ 
tions  and  their  solutions,  he  could  learn  how  to  do  this 
in  approximately  20  minutes.  This  same  user  might  also, 
in  a  few  additional  minutes,  learn  how  to  do  algebraic 
manipulations  so  that  he  might  seek  analytic  solutions 
to  this  differential  equation. 

Another  feature  of  CAMA  is  the  economy  of  its  oper¬ 
ations.  Although  many  of  the  parts  are  not  optimally 
coded  in  the  sense  of  maximum  speed  of  operation,  all 
parts  in  CAMA  are  controlled  in  such  a  way  that  costs 
are  minimized.  The  charging  algorithm  on  the  central 
computer  depends  upon  many  factors ,  two  of  which  are : 
the  amount  of  storage  being  used,  and  the  length  of  time 
storage  is  being  used.  In  other  words,  the  integral  of 
the  amount  of  storage  over  time  determines  the  major  cost 
of  computer  use.  If  the  user  pauses  to  think,  the  CAMA 
system  automatically  moves  all  of  his  operations  out  on 
to  disk  files,  and  keeps  only  a  small  portion  of  his  pro¬ 
gram  in  the  computer  to  await  his  next  command.  Thus,  the 
charges  during  this  thinking  time  are  very  small.  They 
might  perhaps  be  as  low  as  $3  for  a  half-hour's  worth  of 
thought.  When  the  user  becomes  active  again,  the  system 
responds  very  quickly,  bringing  his  problem  back  into  the 
virtual  memory  and,  for  most  operations,  acting  as  if  it 
were  responding  immediately  to  his  request  for  service. 

There  are  three  basic  modes  of  operation  of  the  CAMA 
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system:  the  immediate  mode,  the  delay  mode,  and  the  batch 

mode.  The  immediate  mode  responds  at  once  to  the  user's 
request.  When  he  asks  for  a  certain  operation,  the  machine 
returns  the  results  to  him  as  quickly  as  it  can  produce 
them.  The  delay  mode  is  somewhat  different.  If,  for  ef¬ 
ficiency,  the  user  wants  to  stack  a  series  of  operations 
and  invoke  them  as  a  unit,  he  may  specify  these  opera¬ 
tions  much  as  he  would  in  ordinary  programming,  except, 
of  course,  that  he  is  using  graphical  input  and  output. 

When  all  the  operations  to  be  invoked  have  been  stacked, 
the  user  then  causes  them  to  be  executed.  He  can,  if  he 
wishes,  build  into  this  stack  of  operations,  monitoring 
features  which  allow  him  tc  interrupt  or  observe  the 
processing.  The  third  mode  of  operation  is  called  batch, 
although  it  is  not  a  batch  operation  in  the  ordinary  sense. 
It  resembles  the  delay  mode,  except  that  the  operations 
are  executed  later,  when  the  user  is  off  the  terminal. 

This  is  desirable  in  some  cases  because  off-terminal 
[non-interactive)  operations  are  cheaper  than  on-terminal 
ones . 

All  modes  of  operation  permit  the  user  to  keep,  if 
he  wishes,  any  intermediate  results  on  the  disk  files  (up 
to  the  limits  of  his  allocated  storage)  and  use  them  as 
the  basis  of  further  operations.  In  mathematical  processes 
it  is  frequently  necessary  to  back  up  and  do  something  a 
different  way.  If  the  user  kept  sufficient  intermediate 
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information,  this  backing  up  process  is  rather  easy. 

For  example,  in  solving  a  differential  equation,  he 
may  find  that  the  method  he  has  chosen  is  unstable. 

By  merely  accessing  the  data  storage  pack  which  contains 
the  original  specification  of  the  differential  equation, 
he  can  seek  a  more  stable  method  of  solutions  without 
having  to  respecify  the  differential  equation.  Further¬ 
more,  by  keeping  appropriate  pieces  of  infomation  on  disk 
files,  he  can  resume  operations  at  a  later  time  without 
starting  the  problem  over  from  the  beginning.  This  cap¬ 
ability  is  highly  important  in  mathemati<  analysis  be¬ 
cause  the  student  often  doesn't  know  where  he  is  going  or 
how  to  get  there,  but  rather  is  conducting  experiments  in 
a  mathematical  language. 

In  algebraic  manipulation,  the  user  cannot  always 
specify  everything  he  wants  by  simple  commands.  To  over¬ 
come  this  difficulty,  CAMA  provides  many  commands  derived 
from  basic  algebraic  manipulations  such  as  the  commutative 
law,  the  distributive  law,  the  associative  law,  and  so 
forth.  Furthermore,  built  upon  these  primitive  operations 
is  a  hierarchy  of  more  complex  operations,  each  of  which 
can  be  called  individually  under  the  control  of  the  user 
at  the  console.  Or  he  may  define  new  combinations  for 
his  own  use. 

The  algebra  or  calculus  built  into  the  CAMA  system 
is  not  limited  to  ordinary  algebra.  Predefined  matrix 
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algebra,  physical  vector  algebra,  and  several  others  are 
also  available.  More  complicated  algebras  can  be  defined 
and  some  of  the  CAMA  designers  are  presently  incorporating 
these  into  the  system. 

All  CAMA  operations  are  under  direct  user  control 
via  light-button  selection. ^  Because  of  the  small  size 
of  the  display  screen,  only  a  selected  group  of  operations 
can  be  displayed  at  ony  one  time.  However,  by  a  simple 
command  at  the  teletype,  the  user  can  add  or  delete  from 
the  screen  light  buttons  which  specify  other  actions. 

It  is  relatively  easy  to  define  a  new  operation 
and  its  associated  light  button  by  identifying  a  parti¬ 
cular  light  button  with  a  particular  task  (a  simple  com¬ 
mand  does  this) ,  and  defining  that  task  as  a  sequence  of 
other  tasks.  The  user  can  also  define  his  own  operations 
either  as  a  combination  of  existing  primitives,  or,  if  he 
is  sufficiently  knowledgeable,  as  a  combination  of  primi¬ 
tives  he  himself  has  defined. 
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3 .  HARDWARE  CONFIGURATION 

The  University  of  Michigan  Computing  Center  has  an 
IBM  360/67  duplex  computer  with  a  four-billion-byte  virtual 
memory  consisting  of  about  1.5  million  bytes  of  directly 
addressable  core  storage  and  the  remainder  on  an  automati¬ 
cally  paged  drum  (see  Figure  1) .  Auxiliary  storage  con¬ 
sists  of  disk  files  of  400-million  bvtes,  a  400-million- 
byte  data  cell,  and  several  magnetic  tape  units.  The 
main  computer  is  accessed  on  a  timesharing  basis  through 
many  ports.  CAMA  uses  the  one  known  as  the  Data  Concen- 

(A  \ 

trator.  Over  one  hundred  other  remote  data  terminals 

can  be  connected  simultaneously  via  telephone  lines  to 
the  central  computer.  Accessible  of  course  are  other  things 
such  as  high-speed  printers,  punches,  card-readers,  and  the 
like.  A  large-bed  Calcomp  plotter  is  also  available. 

In  a  building  several  blocks  away  is  the  terminal 
computer,  a  Digital  Equipment  Corporation  PDP-8  with  two 
103  Dataphones  and  one  201  Dataphone.  Two  teletypes  are 
connected  to  the  PDP-8  through  two  103  dataphones,  and 
the  PDP-8  is  connected  to  the  central  computer  through 
the  Data  Concentrator  by  the  201  data  link.  All  of  these 
links  are  dialable  facilities  through  the  regular  telephone 
lines.  Associated  with  the  terminal  computer  is  a  disk 
file  system,  a  display  with  a  light  pen,  a  high-speed  paper- 
tape  reader/punch,  a  Grafacon,  and  a  small  Calcomp  plotter. 
All  of  these  facilities  can  be  used  by  the  CAMA  system. 


HARDWARE  CONFIGURATION 
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4.  CENTRAL  COMPUTER  SOFTWARE 

The  Michigan  Terminal  System  (MTS)  is  the  operating 
system  written  by  the  Computing  Center  staff  at  the  Uni¬ 
versity  of  Michigan  for  the  IBM  360/67  computing  system. ^ 
This  system  permits  the  concurrent  handling  of  a  large 
number  of  jobs  either  in  batch-processing  mode  or  time¬ 
sharing  mode.  MTS  is  a  multiprogramming  system  that  over¬ 
sees  all  computational  activities,  including  control  of 
access  to  the  computer,  management  of  and  operations  on 
files,  translation  of  source-language  programs,  execution 
of  object  programs ,  and  maintenance  of  all  accounting  re¬ 
cords  . 

Usually  MTS  treats  all  active  users  alike,  rendering 
service  in  round-robin  fashion.  However,  MTS  may  assign 
priority  levels  to  users  when  more  than  one  user  is  com¬ 
peting  for  the  same  computing  resource. 

The  user  communicates  with  the  operating  system 
through  tht  MTS  command  language ,  an  artificial  language 
with  a  grammar  and  vocabulary  defined  by  the  authors  of 
MTS. 

In  addition  to  MTS  with  its  supervisory  services, 
the  system  library  contains  programs  that,  for  example, 
allow  a  user  to  edit  a  line  file,  to  debug  a  program  using 
symbolic  references,  to  obtain  file  statistics,  to  obtain 
a  summary  of  his  computer  account  statistics,  and  to  mount 
magnetic  tapes. 
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5 .  DATA  STRUCTURES 

The  data  structure  for  CAMA  in  the  central  computer 
was  designed  to  meet  the  objective  of  adaptability  and 
ease  of  use  for  non-expert  users  of  the  overall  system. ^ 

The  structure  is  built  around  data  blocks  that  are  called 
packs.  A  pack  is  subdivided  into  three  regions  (see 
Figure  2) :  an  expandable  negative  region ,  a  32-byte  aero 
region,  and  an  expandable  positive  region. 

The  positive  region  contains  the  data  being  referenced. 
The  zero  region  contains  the  information  necessary  for  the 
handling  of  the  packs.  This  includes  the  name  of  the  pack, 
a  back-pointer  to  a  list  (also  stored  in  a  pack)  which  refer¬ 
ences  this  pack,  a  type  which  is  indicative  of  the  kind  of 
information  stored  in  the  pack,  as  well  as  a  number  of  indi¬ 
cators  which  give  the  size  of  the  pack,  length  of  data 
stored,  and  length  of  negative  region.  The  content  of 
the  negative  region  is  not  specified  by  the  designers  but 
is  available  for  knowledgeable  users. 

The  pack-handling  system  of  CAMA  consists  of  a  group 
of  simple  linked  lists  which  themselves  are  stored  in 
packs  and  which  are  referenced  by  an  associative  language. 

It  has  been  optimized  in  the  sense  that  it  does  not  use 
much  core  storage,  and  only  needed  parts  of  it  are  loaded 
into  active  storage.  A  disadvantage  of  the  optimization 
is  that  locating  packs  may  require  the  searching  of  long 


DATA  STORAGE  PACK  STRUCTURE 
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lists.  Other  data  systems  may  be  linked  with  packs.  The 
negative  region  provided  for  in  the  packs  allows  the  user 
to  store  in  the  packs  headers  and  pointers  of  his  own 
choosing  so  that  he  may  incorporate  such  systems  as 
SLIP, (7)  L6,<8)  TRAMP, (9)  or  the  Set  Theoretic  Data 
Structure. (10) 

Data  packs  may  be  created  or  destroyed  at  the  will 
of  the  user.  They  may  be  expanded  or  contracted  in  size 
depending  on  the  quantity  of  information  being  stored. 

They  may  be  removed  from  active  storage  and  stored  on 
disk  files  and  retrieved  when  needed  under  automatic 
control  of  the  program  or  under  the  control  of  the  user. 
When  the  user  pauses  in  his  activity  to  think  or  do 
other  chores,  all  the  data  can  be  shifted  automatically 
to  disk  files  leaving  only  a  very  small  program  in  con¬ 
trol  . 

The  packs  are  so  structured  that  the  data  in  them 
may  be  accessed  from  any  suitably  coded  subroutine  written 
in  FORTRAN.  This  allows  even  the  least  skilled  programmer 
to  write  subprograms  and  to  use  his  existing  subprogram 
written  in  FORTRAN,  MAD/I ,  ALGOL,  or  other  common  languages 
without  modification.  Thus,  common  procedures  using  arrays 
such  as  matrix  addition,  multiplication,  etc.  can  be  drawn 
from  existing  libraries. 
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6.  TASK  QUEUE 

All  CAMA  operations  in  the  central  computer  are 
divided  into  units  referred  to  as  tasks .  ^  The  tasks 
may  be  defined  by  the  user  or  may  be  part  of  the  CAMA 
system.  Tasks  may  be  generated  by  the  action  of  the  user 
at  the  console  or  by  the  system  when  it  detects  an  error 
or  when  some  internal  activity  needs  attention.  They 
are  stacked  on  a  queue  and  are  processed  on  a  first-on 
first-off  basis,  unless  priorities  are  requested.  Prior¬ 
ities  are  given  when  data  is  being  transmitted  from  the 
terminal,  when  errors  occur  in  processing  such  as  data 
overflow  in  packs,  when  information  is  being  processed, 
or  when  requested  by  a  select  group  of  commands.  After 
the  priority  items  are  processed,  the  tasking  system  re¬ 
turns  to  the  first-on,  first-off  basis  of  processing. 

At  the  bottom  of  the  queue,  a  series  of  tusks  con¬ 
stantly  survey  data  packs  and  subprograms  to  see  if  they 
may  be  discharged.  Thus,  during  the  dwell  times,  data 
management  may  take  place,  whereas  when  the  user  is 
most  active  his  needs  are  serviced  as  quickly  as  possible. 
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7.  DISPLAY  FILE  PROCEDURES 

One  part  of  the  CAMA  system  is  a  group  of  procedures 
known  as  display  file  (or  DF)  routines.  ^  These  allow 
the  user  at  the  graphics  terminal  to  assemble  display 
files  in  the  central  computer,  transmit  them  to  the  ter¬ 
minal  computer,  load  them  into  the  storage,  and  control 
the  displaying  of  the  display  files.  A  display  file  may 
consist  of  line  drawings,  descriptions  of  characters  and 
symbols,  or  calls  on  other  display  files.  Thus  any  pic¬ 
ture  or  series  of  symbols  generated  in  the  central  com¬ 
puter  can  be  easily  displayed. 

A  particular  feature  of  the  terminal  computer  allows 
display  files  to  call  other  display  files  as  subroutines. 

For  example,  if  a  pattern  described  by  a  display  file  is 
to  be  displayed  at  more  than  one  location  on  the  display 
screen,  only  one  copy  of  that  pattern  need  be  defined 
with  as  many  references  to  it  as  necessary  or  desired  in 
other  display  files.  In  particular,  this  feature  allows 
the  user  to  complement  his  set  of  characters  and  symbols 
with  the  standard  character  set  which  has  been  defined 
for  the  display  screen  of  the  terminal  computer. 

The  DF  routines  include  light  pen  and  Grafacon  support. 
These  routines  enable  either  the  light  pen  or  Grafacon  and 


then  return  data  to  the  user. 
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8.  DRAWING  CAPABILITY 

Within  the  CAMA  system  is  an  adaptation  of  a  simple 
drafting  language  developed  at  the  University  of  Michigan 
known  as  DRAWL.  This  adaptation  uses  the  DF  routines 

to  produce  pictures  on  the  display  or  hard  copies  on  the 
Calcomp  plotters  at  either  the  terminal  or  at  a  central 
computer  facility.  DRAWL  can  describe  any  three-dimen¬ 
sional  object  by  assembling  objects  into  larger  objects, 
and  then  rotate  that  object  or  project  it  onto  any  plane. 
Perspective  views  can  also  be  obtained. 

The  principal  use  of  DRAWL  in  CAMA  is  for  the  drawing 
of  curves  which  are  the  results  of  calculations,  producing 
axes  for  graphs,  labeling  of  graphs,  and  producing  bar 
charts.  At  present,  there  is  no  provision  for  the  removal 
of  hidden  lines,  but  we  plan  to  include  this  option  at  a 
later  date. 
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9.  DYNAMIC  LOADER 

The  CAMA  system  presently  incorporates  approximately 
600  subprograms  for  the  central  computer,  exclusive  of 
those  that  the  user  may  wish  to  add,  but  only  a  small 
portion  of  them  need  be  loaded  at  one  time.  Because  it 
would  be  impossible  and  prohibitively  expensive  to  have 
all  600  in  virtual  memory  at  all  times,  we  have  provided 
for  the  dynamic  loading  or  unloading  of  subprograms  at 
the  will  of  the  user  or  under  program  control. '  '  An 

infrequently  used  program  may  be  called  in  from  disk 
storage  when  needed  and  re  leased  when  not  needed.  On 
the  other  hand,  frequently  used  programs  may  be  loaded 
and  kept  in  virtual  memory  as  long  as  desired. 
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10.  TRANSLATORS 

The  interpretation  of  the  symbolic  patterns  created 
in  the  terminal  computer  and  stored  in  the  central  com¬ 
puter  is  a  matter  for  the  user  to  decide.  He  may  create 

his  own  translator  to  interpret  patterns,  or  he  may  use 

(13) 

a  translation  already  defined.  Present  translations 

include  some  so  simple  as  to  take  a  line  of  symbols  and 
produce  a  line  of  FORTRAN  code;  others  perform  numerical 
integrations,  or  interpret  expressions  involving  matrices 
or  other  algebraic  entities.  Some  take  an  ordinary  differ¬ 
ential  equation  and  produce  a  program  for  its  solution  by 
means  of  one  or  more  numerical  processes. 

The  existing  translators  were  constructed  with  the 
aid  of  several  processors  which  the  knowledgeable  user 
may  employ  to  construct  his  own  translators.  These  in¬ 
clude  a  lexical  scanner,  a  generalized  macro  facility, 
and  a  table-driven  parser. 

The  macro  facility  allows  the  user  to  define  a 
"language"  of  his  own  in  terms  of  already  existing  lan¬ 
guages  such  as  FORTRAN,  MAO/I ,  PL/I,  or  others,  He  may, 
in  fact,  define  a  new  language  in  terms  of  another  one 
that  he  has  previously  defined.  The  macro  facility  allows 
the  production  of  as  many  lines  of  output  code  as  are  de¬ 
sired  from  a  single  line  of  input  code.  There  is  a  limited 
but  most  useful  context-interpreter  in  the  macro-producer 
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which  allows  modifications  of  the  productions  on  the 
basis  of  the  modes  of  variables,  counts,  operations  indi¬ 
cated,  and  other  parts  of  the  input  strings. 

The  lexical  scanner  delimits  the  syntactic  units  of 
any  line  of  code  and  sets  up  appropriate  tables.  The 
scanner,  of  course,  depends  on  user-defined  tables  which 
define  operators,  delimiters,  etc. 

The  parser  (currently  a  simple  precedence  parser) 
takes  the  delimited  input  strings  and  produces  sets  of 
triples.  The  precedences  are  set  in  a  table  which  can 
be  defined  by  the  user  if  he  so  desires.  For  the  several 
predefined  languages,  precedence  tables  already  are  avail¬ 
able.  The  user  can  change  precedences  and  the  external 
representation  of  operators.  Af  an  example,  he  might 
wish  to  name  a  variable  and  denote  the  multiplication 
operation  by  M.  Of  course,  the  user  may  reduce  readability 
in  his  "language,"  but  CAMA  does  allow  him  to  make  such 
c !  ioices . 

The  triples  which  are  the  result  of  the  parsing  oper¬ 
ation  are  sent  through  a  macro  processor,  which  in  turn 
produces  code  in  the  base  language.  Sometimes  saverol 
passes  through  a  parser  and  macro  processor  are  necessary 
to  produce  such  code. 

The  i  ase  language  may  be  a  language  such  as  FORTRAN, 
which  requires  the  execution  of  a  compiler  to  produce 
machine  code.  However,  for  the  immediate  mode  of  operation, 
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the  base  language  is  a  collection  of  special  calls  within 
the  CAMA  system  which  can,  in  effect,  call  any  subroutine 
in  the  library  and  cau;e  it  to  operate  on  any  data  pack  or 
group  of  data  packs.  All  predefined  operations  can  be 
called  dynamically .  With  these  special  calls  as  a  base 
langauge,  operations  can  be  performed  immediately  as  they 
would  be  in  an  interpretive  language.  This  is  not  a  very 
efficient  process,  however,  and  is  not  in  general  used  in 
the  delay  mode  of  operation.  Instead,  in  the  delay  mode, 
a  compiler  or  an  assembler  is  called  in  to  handle  the 
base  language  translation.  Future  productions  will  be 
in  machine  code. 

Although  still  in  a  formative  state,  the  powerful 
MAD/I  compiler  at  the  University  of  Michigan  has  made  the 
coding  of  CAMA  very  much  easier.^ 15 ^  The  translators 
and  much  of  the  future  development  depend  on  th*s  com¬ 
piler. 
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11.  ALGEBRAIC  MANIPULATION 

The  graphical,  interactive  nature  of  CAMA  makes 
algebraic  manipulations  more  practical  than  in  older 
systems.  There  is  distinct  advantage  in 

being  able  to  see  mathematical  symbols  as  they  usually 
appear  in  the  mathematical  literature  as  opposed  to  see¬ 
ing  them  as  rather  obscure  mnenomics.  As  an  idea  is 

(19) 

easily  lost  after  a  delay  of  15  seconds,  the  immedi¬ 

ate  viewing  of  the  results  of  an  algebraic  manipulation 
is  far  juperior. 

At  present,  the  CAMA  system  has  only  a  limited  alge¬ 
braic  capability,  but  is  growing  as  it  is  used.  All  the 
algebraic  operations  are  based  on  a  group  of  primitive 
operations.  These  include  identifying  an  entity,  moving 
an  entity,  substituting  an  expression,  applying  the  asso¬ 
ciative  law  of  addition  or  multiplication  or  the  inverse, 
applying  the  commutative  law  of  addition  or  multiplication, 
applying  the  distributive  law,  and  the  combining  of  like 
adjacent  terms.  Upon  these  primitive  operations  more  com¬ 
plex  operations  are  built.  For  example,  the  gathering  of 
like  terms  from  a  long  expression  is  accomplished  by  identi¬ 
fying  one  term  as  an  entity,  searching  for  identical  entities, 
moving  the  entity  to  an  adjacent  position,  and  combining 
terms.  The  inverse  operation  is  also  available  and  is 


sometimes  useful. 
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Many  operations  are  currently  defined  foi  one-dimen¬ 
sional  expressions,  that  is,  expressions  in  which  only 
the  X  positions  of  the  symbols  are  significant.  However, 
a  limited  but  growing  set  of  two-dimensional  operations 
is  also  available.  There  are  many  problems  associated 
with  the  ambiguous  interpretation  of  two-dimensional  ex¬ 
pressions  which  have  not  been  entirely  resolved.  Many 
of  these  problems  are  easily  bypassed,  however,  because 
the  user  can  watch  the  progre ■ 3  of  the  manipulation  and 
interject  the  correct  interpretation  if  the  programmed 
interpretation  is  incorrect. 

Inasmuch  as  the  algebraic  operations  are  defined  in 
terms  of  primitives,  and  since  any  user  can  include  or 
delete  any  operation  at  will,  the  ultimate  capability  in 
terms  of  different  algebras  is  great.  For  example,  it 
was  relatively  easy  to  include  many  operations  of  matrix 
algebra  and  calculus  and  physical  vector  algebra  and  cal¬ 
culus  in  this  system.  Tensor  algebra  and  calculus  is  now 
being  included.  Although  we  have  not  pursued  it  to  any 
extent,  it  seems  possible  to  define  algebras  to  manipulate 
physical  entities  such  as  machine  parts,  structural  elements, 
or  picture  elements. 
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12.  TERMINAL  PROCEDURES 

All  the  activities  in  the  terminal  computer  are  im¬ 
bedded  in  an  operating  system  known  as  RAMP.  This 

is  a  multiprogramming  system  which  takes  care  of  all  such 
services  as  processing  interrupts,  transmitting  data  to 
and  from  the  data  phones,  structuring  display  files,  inter¬ 
preting  light-pen  hits  and  Grafacon  interrupts.  It  handles 
the  storage  and  retrieval  of  information  from  the  local 
disk  files,  prepares  data  for  the  local  Calcomp  plotter, 
and  in  general  handles  all  the  management  of  buffers  and 
subprograms  within  the  terminal  computer. 

Several  procedures  for  the  terminal  computer  are 

(22) 

specifically  designed  for  CAMA.  '  One  such  procedure 
allows  a  user  to  define  any  symbols  he  chooses  and  store 
them  for  future  use  in  the  central  computer's  data  packs. 
Thus  he  can  create  any  of  the  commonly  used  mathematical 
symbols  such  as  partial  derivative  symbols,  integral  sym¬ 
bols,  script  letters,  Greek  letters,  or,  for  that  matter, 
any  pattern.  Associated  with  each  symbol  are  a  number  of 
attributes,  including  a  primary  reference  point  which 
identifies  the  X  and  Y  coordinates  of  the  symbol  when 
used  in  an  expression,  a  name,  and  type.  The  attributes 
also  include  a  group  of  secondary  reference  points  which 
can  serve  a  number  of  roles  including  points  of  attach¬ 
ment  foi  other  symbols  and  for  connectors  in  such  things 
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as  electrical  circuits.  At  present,  approximately  two- 
hundred  commonly  used  symbols  have  been  defined  and  stored 
in  appropriate  packs  in  the  central  computer. 

The  user  may  select  a  subset  of  symbols  from  the  set 
of  predefined  symbols  and/or  add  to  that  set  any  that  he 
defines  himself.  This  set  becomes  a  menu  from  which  he 
can  construct  the  mathematical  expressions  or  other  sym¬ 
bolic  patterns.  This  procedure  allows  the  user  to  select 
the  symbols  by  a  light  pen,  or  through  the  Graf aeon,  and 
locate  them  in  whatever  pattern  he  feels  is  meaningful. 

This  procedure  allows  him  to  move  the  symbols,  edit  the 
pattern,  or  add  and  delete  symbols.  When  the  pattern 
satisfies  him,  he  transmits  it  to  the  central  computer. 

The  information  transmitted  includes  the  x  and  y  coordin¬ 
ates  of  the  primary  reference  point  of  the  symbols  as 
well  as  the  name,  type,  size,  and  other  pertinent  attributes. 
This  information  is  stored  in  a  pack  named  by  the  user. 

Then,  by  the  same  procedure,  he  may  construct  other  ex¬ 
pressions  or  patterns  until  he  has  a  complete  set  for 
his  purposes. 
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13.  ABSTRACT 

This  paper  describes  CAMA  (Computer-Aided  Mathematical  Analysis) , 
which  is  a  system  that  attempts  to  handle  all  conceivaMe  mathematical 
operations,  from  simple  numeric  procedures  to  complex  algebraic  or 
set-theoretic  manipulations.  CAMA  operates  in  a  timesharing  environ¬ 
ment  with  a  large  central  computer  and  a  remote  terminal  computer  with 
graphical  devices . 

Some  of  the  features  of  CAMA  are:  the  input  and  output  cf 
mathematical  symbols  in  their  usual  mathematical  representation;  the 
ability  to  manipulate  these  symbols  according  to  predefined  algebraic 
laws;  the  definition  by  the  user  of  other  algebraic  laws;  the  defini¬ 
tion  of  symbols  with  user-prescribed  meanings;  the  automatic  transla¬ 
tion  of  expressions  or  equations  into  any  of  several  languages;  and 
numerical  calculations.  The  user  can  invoke  any  of  these  tasks  through 
the  graphical  terminal. 
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